Higth memory and CPU usage when playing video in bilibili.com
Categories
(Core :: Graphics: WebRender, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr60 | --- | unaffected |
firefox67 | --- | unaffected |
firefox68 | --- | unaffected |
firefox69 | --- | verified |
People
(Reporter: nayinain, Assigned: sotaro)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0
Steps to reproduce:
- Open a clean Profile.
- Open https://www.bilibili.com/video/av54754681/
- Play the video in the page for a while.
Actual results:
Higth memory and CPU usage
Expected results:
Sorry for my bad English.
2019-06-10T12:41:12: INFO : Narrowed inbound regression window from [42622b5a, bbab037b] (3 builds) to [ef0b9879, bbab037b] (2 builds) (~1 steps left)
2019-06-10T12:41:12: DEBUG : Starting merge handling...
2019-06-10T12:41:12: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=bbab037b0f9fc6e460e62e3f4da98e984f83714b&full=1
2019-06-10T12:41:13: DEBUG : Found commit message:
Bug 1556340 - Make D3D11TextureData and DXGIYCbCrTextureData alive during host side usage with WebRender r=nicalBy Bug 1555544 , it became clear that D3D11TextureData and DXGIYCbCrTextureData should not be deleted before calling >>RenderDXGITextureHostOGL::EnsureLockable() / RenderDXGITextureHostOGL::EnsureLockable().
With WebRender, the EnsureLockable()s are called on RenderThread asynchronously. Then for achieving the above, it is simpler just to keep >>D3D11TextureData and DXGIYCbCrTextureData alive during host side usage.
There is already a mechanism to do it. By using NotifyNotUsed, it could be done.
Differential Revision: https://phabricator.services.mozilla.com/D33469
2019-06-10T12:41:13: DEBUG : Did not find a branch, checking all integration branches
2019-06-10T12:41:13: INFO : The bisection is done.
2019-06-10T12:41:14: INFO : Stopped
Assignee | ||
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Comment 2•5 years ago
|
||
The following TextureClient is not recycled, it might be related.
https://searchfox.org/mozilla-central/source/gfx/layers/client/CanvasClient.cpp#115
Assignee | ||
Comment 3•5 years ago
|
||
Updated•5 years ago
|
Assignee | ||
Comment 4•5 years ago
•
|
||
Assignee | ||
Updated•5 years ago
|
Pushed by sikeda@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/ff570f169670 Recycle TextureClient in CanvasClient2D with WebRender r=nical
Comment 6•5 years ago
|
||
bugherder |
Comment 7•5 years ago
|
||
Can you merge this change to beta so that this bug won't hit release? I can guarantee that this site is VERY popular in China.
Among teenagers, it has even more than 80% coverage.
Comment 8•5 years ago
|
||
This regression was caused by bug 1556340 within Nightly 69, thus Beta 68 should not be affected. Does Beta have a problem on this website?
Or do you want to imply bug 1556340 should be uplifted to Beta as well?
Comment 9•5 years ago
|
||
Does Beta have a problem on this website?
I believe so
but I'm bot sure about D3D11TextureData
Updated•5 years ago
|
Comment 13•5 years ago
|
||
== Change summary for alert #21525 (as of Wed, 19 Jun 2019 05:52:34 GMT) ==
Improvements:
16% raptor-motionmark-animometer-firefox linux64-shippable-qr opt 41.30 -> 47.85
11% raptor-motionmark-animometer-firefox windows10-64-shippable-qr opt 39.42 -> 43.58
10% raptor-motionmark-animometer-firefox windows10-64-shippable-qr opt 39.52 -> 43.64
For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=21525
Updated•5 years ago
|
Comment 14•5 years ago
|
||
Hello,
Reproduced the issue using Firefox 69.0a1 (20190609214350) on Windows 10x64. After playing the video for a while the CPU and memory usage increased drastically.
The issue is verified fixed with Firefox 69.0b8 (20190725174626) on Windows 10x64, Ubuntu 18.04, macOS 10.14. The CPU and memory usage remains at normal values after playing the video some time while using WebRender.
Comment 15•5 years ago
|
||
Updating the flag for 69.0b8. Sorry for the mistake.
Updated•5 years ago
|
Description
•